Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/001467_daemon _Mon Jun 28 14:42:34 1993.msg

Internet Message Format | 1994-01-24 | 7KB

Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA17673; Mon, 28 Jun 93 14:42:37 MET DST
Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA17669; Mon, 28 Jun 93 14:42:34 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA24585; Mon, 28 Jun 1993 15:05:51 +0200
Received: from localhost by moose.cs.indiana.edu
    (5.65c/9.4jsm) id AA21671; Mon, 28 Jun 1993 08:05:49 -0500
From: Marc VanHeyningen <[e-mail]>
To: [e-mail]
Subject: browser execution
Date: Mon, 28 Jun 1993 08:05:49 -0500
Message-Id: <[e-mail]>
Sender: [e-mail]

Responding to a few things by various people...

George Phillips <[e-mail]> says:
>Semantics: decode the "encoded-URL", grab it and execute it
>with the rest of the URL.  I used the  "//" notation so
>that executables can ouput "/" rooted URLs without having
>to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
>We can do the "encoded-URL" any way we like, but suppose that
>: -> ; and / -> \.  A full exec: URL might look like:
>
>    exec://file;\bin\rn.html/comp/sources/misc

I'd be more inclined to encode the URL with the general percent escape
notation, but that's just me.

(Unrelated question:  Consider the URL http://foo/search?bar%2Bbaz --
how many search keywords does it have, and what are they?  My
inclination is to interpret it as one keyword "bar+baz", though that's
inconvenient for the server since it can't just do all the percent
substitution immediately upon receiving the object.)

>However, with the MIME executable content type, I'd expect that
>most exec: URLs would point to files, so file: would be the default.
>Additionally, the browser might have some notion of a PATH for
>exec: files (possibly as a first-level security mechanism), so the
>whole thing could be shortened to:
>
>    exec://rn.html/comp/sources/misc

This sounds a bit more portable and a bit less anxiety-inducing as far
as security is concerned.  A special directory (or set of aliases, or
something) of safe commands described with somewhat abstract names
could work out OK.  The result is that your local commands end up of
the form:

    exec://mail-rfc822/[e-mail]

or something like that.  Whether this is better than the form:

    mail-rfc822://[e-mail]

(or something like that) is debatable either way; I think either is
probably workable as long as the number of different things you can do
that way is rather small, considered carefully, and centrally
registered in some fashion.

Tony Sanders <[e-mail]> responds:
>SAS strikes again (server aversion syndrome :-)
>
>    content-type: application/x-csh

No!  Anything but the Cshell!  Nobody move, or I post Tom Christiansen
to the mailing list! :-)

>My reasoning:
>  o Browsers cannot change on a whim, because for the Web to be truly
>    useful to the user community at large all browsers must support the
>    **same** set of features (to a large extent anyway).
>  o Therefore we **must** have a definition for the browser that is simple
>    and complete such that any features you might ever want can be done
>    in a server.

I agree here, which is why I'm hesitant to extend things to a general
execution type since programs (particularly, say, cshell programs) are
inherintly non-portable.  I suppose we could try to agree on a
language to specify programs to be executed in.  Such a language would
need a number of attributes:

- Highly portable, will run on UNIX boxes, DOS boxes, Macs, whatever
- Freely available
- Can work in a "paranoid" fashion whereby it is reasonably safe to
  execute untrusted code with it

I'm not sure such a language can even exist.  (Perl meets the first
two criteria, at least.)  I'm pretty sure that inventing it is more
than we can or should try to do.

>I'm not a purist or anything, I think it's fine if we want the browser to
>support things like gopher and ftp directly but at some point we are going
>to have to draw the line if we want most browsers to support a common
>set of features (even <IMG> is a good example of this problem).

I concur; one problem is that most people will generally use just one
browser and thus they'll write documents assuming that everyone else
uses it too.  I've seen documents that rely on IMG too much, given the
number of browsers that don't support it.

George Phillips <[e-mail]> answers:
>Servers are not _that_ easy to write.  They are if you're running UNIX
>and you have either inetd.conf privileges or know how to do sockets.
>Who knows what you'd have to do under VMS or MVS and you just can't
>do them under MS-DOS.  On the other hand, writing a program which
>dumps some HTML to a file is easy and possible under all systems.
>It's very similar to adding to a server, but anybody, not just the
>server administrator can do it and they can share with other non-privileged
>users.

Servers _can be_ easy to write.  A base server could allow you to
easily add new functionality of the variety you discuss without
needing to understand the details of UNIX sockets (not that they're
really that complicated anyway.)  Plexus, for example, allows this.
Don't confuse limitations of particular implementations with
limitations of HTTP servers in general.

>Even if you can easily run a server, you've got some security problems
>to deal with.  Having a browser that will execute code (or URLs, whatever)
>from documents is a little scary; having a server that anyone can
>connect to execute code is really scary.  With the browser executing
>code you leverage off the normal system authentication.  With a server,
>you have to re-invent that.  Sure, these features are coming and
>that's good; but you're building up an awful lot of stuff to solve
>a simple problem.

Servers can run without privilige; ours runs as id "daemon" and
doesn't have the priv to do much other than dequeue other people's
print jobs.  Surely webmasters don't run their HTTP server as root?

Browsers, on the other hand, have to run as users and are thus capable
of harming their users; I find using "normal system authentication"
(as it exists on most machines) to run code in this kind of situation
highly undesirable.

>Well, if you want to add features you have a choice.  Either make it
>harder for the browser writers or make it harder for the server writers.
>I maintain that the exec: URL scheme makes it a little harder for
>the browser writers but is a boon for server writers since it truly
>makes it easy to write a server (just like the simple inetd scripts,
>but you don't need privilege).

Except that what has been written isn't a server at all, it's just a
program.  It doens't provide a service to anyone except the person (or
small group of people) who have examined it, decided it safe, and
placed it on their list of commands for which exec:ing is permissible.
(unless this procedure is not used, in which case it's a security hole
you could drive an aircraft carrier through.)

- Marc
--
Marc VanHeyningen  [e-mail]  MIME, RIPEM & HTTP spoken here